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^ Program  debugging  la  a tlaw  consuodng  process.  Coventlonal  debugging 
techniques  and  aids  typically  give  the  user  a narrow  view  of  the  program's 
operation,  making  debugging  difficult.  A debugging  system  that  would  present* 
a clear  overall  picture  of  a program's  behavior  and  would  be  both  flexible 
and  simple  to  operate  would  be  a valuable  tool.  Such  a system  was  designed 
and  Implemented  In  and  for  MDL,  a high-level  applicative  prograamlng 
language.  This  report  discusses:  the  design  alternatlvea  conaldered  during 
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20.  the  debugging  syeteei'e  design  and  lapleaentatlon  phases,  the  reasons 
for  the  resulting  design  cholcss,  end  the  systea  attributes.  A asjor 
attribute  of  the  systea  (MEND)  Is  that  it  does  not  slaulate  the  program 
being  debugged  but  Instead  monitors  It  from  another  process.  This 
attribute  results  In  a robust  and  viable  debugging  systea,  because  MEND 
need  not  be  modified  In  order  to  handle  each  new  extension  to  MDL  and/or 
each  new  user-defined  primitive. 
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Abftnct 

Pragram  dabugging  it  a tima  canauming  pracaaa.  Canvantienai  debugging 
techniquaa  and  aids  typicaiiy  give  the  uaar  a narraw  view  af  the  pragrem'a 
operation,  making  debuning  difficult  A debuning  qratem  that  would  preaent  a 
clear  overall  pictura  of  a program'a  behavior  and  would  be  both  flexible  end 
aimple  to  operate  would  be  a valuabla  tool.  Such  a.ayatem  waa  deaigned  and 
implemented  in  and  for  MOL,  a Ngh-leval  appiicative  programming  language.  TNa 
report  ditcuaaea:  the  de^gn  altemativea  conaidered  during  the  debugging 
ayatem'a  deaign  and  Implementation  phaaaa,  the  reaaona  for  the  reauiting  deaign 
choicea,  and  the  ayatem  attributea.  A major  attributa  of  tha  ayatem  (NENO)  la  that 
it  doea  not  aimulata  the  program  being  debugged  but  inatead  monitora  it  from 
another  proceaa.  Thia  attribute  raaulta  in  a robuat  and  vlabia  dabugging  ayatem^ 
becauae  MEND  nead  net  be  modHied  in  ardor  to  homie  each  now  extenoion  to 
MOL  and/or  each  new  uaar  defined  primitive. 
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I Introduction 
1.1  Background 

A time-consuming  and  frustrating  aspect  of  computer  programming  ia  the 
debugging  of  faulty  programs.  Current  debugging  techniques  involve  tracing 
through  the  present  operation  of  the  program  and  mentally  comparing  ita  action 
with  one's  concept  of  what  should  be  happening.  With  few  exceptions,  an 
understanding  of  where  the  program  fails  to  conform  to  "correct”  operation  must 
be  made  before  the  cause  of  the  failure  can  be  determined  and  eorraetiva  action 
taken.  TNs  is  where  much  of  the  difficulty  occurs. 

In  conventional  debugging,  It  is  rare  for  the  programmer  to  have  availabla 
any  more  than  the  most  basic  aids.  One  usually  has  to  extrapoiata  from  a bare 
minimum  of  information  (such  as  macNne  generated  error  messages)  or  one  may  be 
buried  under  a large  excess  of  information,  mostly  irrelevant  (such  as  a core 
dump).  Evan  with  the  more  advanced  aids,  the  programmer  typically  gats  but  a 
small  window  into  the  operation  of  the  program  through  whicK  sooner  or  later,  she 
or  he  will  locate  the  problem.  A weli-localized  fault  will  be  rdativaly  easy  to  spot 
compared  to  a global  problem  that  the  programmer  may  only  catch  giimpsas  of 
through  the  debugging  window. 

in  a compiler  language,  the  programmer's  best  hope  is  to  insert  statements 
to  print  intermediate  results  or  to  try  to  separate  the  program  into 
eesier-to-handie  modules.  There  are  a few  more  advanced  aids  available',  but 
their  use  is  limited  Ote  problem  is  that  the  program  la,  in  effect,  firat  translated 
into  a lower-la  vat  language  (generally  "machine”  language)  and  than  axacuted 
intarprativaly  in  that  language.  The  original  symbols  and  syntax  of  the  source 
program  are  lost,  or  saved  only  with  great  difficulty,  making  analysis  and 
manipulation  of  the  executing  program  a vary  painful  process. 

If  the  programmer  is  using  an  interprativa  language  with  facilities  for 
interaction,  things  are  considerably  easier.  The  common  technique  is  to  atop 
execution  at  strategic  points  and  examine  the  state  of  the  environment  Since  tNa 
is  done  interactively,  with  the  source  program  still  available  in  more  or  less  its 
original  form,  tha  causa  of  the  problem  can  oftan  be  found  in  less  time  than  it 
could  otherwise.  One  of  the  best  examples  of  this  approach  is  the  uaa  of  DOT 
(Oyn*nic  Debugging  Tool/Technique)*^. 

DOT  basically  works  with  machina-languaga  programs.  Howavar,  by  fraely 
translating  between  numbers  and  symbols  through  the  use  of  a table  generated  t^ 
the  assembler,  DDT  makes  programs  look  to  the  programmer  like  symbolic 
assembly-language  programs  The  user  of  DOT  can  operate  in  free-run  mode  or  in 
r>-atep  (statement)  mode,  switcNng  between  them  at  will.  In  aithar  case  one  can 
set  a breakpoint  at  any  atatemant,  which  will  cause  execution  to  atop  Just  before 
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th«  ttatanMot  it  axacutMl  Whantvar  ttoppad  In  DDT,  tha  utar  can  axamina  or 
changa  tha  contantt  of  any  locatioa  TNc  can  ba  dona  in  tavaral  data  modat  (a.f., 
untignad  octal,  full  atcii,  tlxbit,  ate.)  Including  tha  uaa  of  aymbolt  to  rapratant 
addrattat.  Arbitrary  numaric  axpramiont  can  alto  ba  avaluatad  without  affacting 
tha  program 

Ona  main  advantaga  of  DDT  it  that  tha  dabugging  anvironmant  it  vary 
timilar  to  tha  languaga  anvironmant  tha  programmar  utad  to  writa  tha  program 
Ona  hat  to  laarn  only  tha  DOT  commandt  rathar  than  an  antiraiy  naw  languaga. 
Anothar  advantaga  it  tha  utar't  ability  to  maka  changat  in  tha  program  and  data 
intaractivaly  at  axacution  tima^  with  raady  ability  for  viawing  tha  ratuitt  of  tha 
changat.  In  addition,  ona  can  quickly  taa  tha  ratuitt  of  tha  changat  and  act 
accordingly. 

Tha  main  daficiancy  of  DOT  it  that,  although  itt  nama  indudat  tha  word 
"dynarrac,”  itt  operation  it  really  ttatic  T)w  application  program  can  run  freely, 
but  whan  tha  programmer  wantt  to  taa  what  it  taking  place,  tha  program  mutt  ba 
ttoppad.  Although  tha  real  intaratt  may  ba  about  changat  on  a grott  tcala, 
parh^  thoutandt  of  program  ttatamantt,  if  ona  doat  net  know  axactly  where  tha 
program  it  mitbahaving,  ona  may  ba  required  to  tutpand  axacution  of  it  every  few 
inttrucUont  to  axamina  variablat  In  ordar  to  obtain  a true  picture  of  tha  profram*a 
behavior.  Thut  tha  programmer  teat  not  whot  1$  taUf^  ploeo,  but  whot  hot  takon 
plaea,  and  through  tmail  windowt  at  that  Thit  it  inaffidant,  and  tha  programmer 
can  become  bogged  down  in  detail  that  hindart  tha  diteovary  of  tha  true  problem 
Tha  dtuation  can  ba  improved  with  tha  uta  of  braakpointt  that  allow  tha  program 
to  axacuta  fraaly  until  a breakpoint  It  reached,  at  which  paint  tha  program  haitt. 
DOT  it  a powerful  tool  but  ttill  laavat  much  to  Im  dadrad  in  a dabugging  tool. 

ESP^*  (Execution  Simulator  and  Pratantar)  it  one  toiution  to  tha  ttatic 
problem  it  really  it  dynamic  in  that  large  amountt  of  data  are  conatantly  being 
diapiayad  for  tha  programmer  wMla  tha  program  it  being  executed  (actually, 
dmulatad).  Tha  information  it  pratantad  in  graphic  form  to  improve  readability  and 
raduca  confudon.  A utar  of  ESP  may  watch  araat  of  tha  ditplay  where  data  of 
particular  intaratt  are  being  pratantad.  Ona  dto  hat  many  optiont  including 
control  over  tha  tpaad  of  axacutiorv  tha  type  and  quantity  of  data  dlaplqradl  and 
tpadd  (more  flaxibla  than  Juat  a bradq)oint)  conditlont  for  halting  axacution.  In 
thit  way  ona  can  atructura  and  control  tha  picture  pratantad  ta  more  aaaily 
undarttand  what  tha  dmulatad  program  It  doing.  And  that  it  ona  Kay  atap  in  tha 
prooatt  of  debugging. 

Uka  DOT,  ESP  hat  daficiandat  alto.  Theta  are  mainly  in  tha  area  of 
editing  and  OOT-lika  examination  of  a faulty  program.  DOT  It  a tophiatleatad 
language  that  ESP  doat  not  attempt  to  anUrtly  raplaca.  Tha  flaw  in  ESP  it  that  it 
It  not  compatibla  with  DOT.  IdttNy  bath  thouM  be  dmultanaeudy  avaUaMa  to  tha 
programmer,  who  can  uta  faolurat  af  aach  at  tha  noad  dktatat. 
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DOT  and  ESP  work  with  a low-level  language  whose  operation  can  be 
shown  fairly  simply.  For  example,  ESP  often  shows  flow  of  control  by  just 
displaying  the  actual  section  of  program  being  executed  and  pointing  to  the  current 
statement^  It  also  draws  lines  to  show  where  branching  has  occurred  and  in  some 
cases  even  indicates  looping.  This  display  philosophy  can  be  readily  extended  to 
higher  level  languages  that  are  line  oriented,  like  BASIC,  but  it  fails  with 
applicative  ones,  like  LISP  or  MDL  The  latter  type  does  not  use  a linear  control 
flow,  but  uses  a complex  depth-first  tree  structure.  Furthermore,  quite 
complicated  data  structures  can  be  buiit  (or  themselves  executed)  that  bear  very 
little  relation  to  the  appearance  of  the  program. 

A good  basic  display  for  MDL  was  used  in  MUMBLE^  (Gerald  Farrell's 
nranitor  and  debugging  aid).  The  code  being  executed  Is  shown  in  stack  form. 
Each  line  shows  a piece  of  code  being  evaluated.  As  each  object  in  the  bottom 
line  is  evaluated;  it  is  replaced  by  a single  downward-arrow  symbol  in  this  line  and 
then  printed  on  a new  line.  In  this  way  the  evaluation  can  be  followed  from  the 
top  level  down  to  the  current  object  being  evaluated.  Furthermore,  after  the 
bottom  is  reached,  the  value  returned  by  each  line  replaces  its  symbol  in  the 
previous  line.  With  this  mechanism,  the  programmer  cen  follow  execution  in  a 
natural  and  reasonably  clear  reprasentatloa 

MUMBLE  had  some  difficulties  arising  from  the  fact  that  it  simulated 
execution  rather  than  just  watching  it  and  letting  it  proceed  naturally.  This  caused 
it  to  run  slowly  and  to  be  complex  and  fragile  At  the  time  MUMBLE  was  written, 
the  MDL  compiler  was  not  yet  perfected  and  the  language  itself  lecked  some  of 
the  multiprocessing  features  that  would  have  mede  simulation  unnecessary.  Later 
Farrell  replaced  MUMBLE  with  a debugger  utilizing  new  software  related  to 
single-stepping  a process,  which  eliminated  the  simulation  but  also  eliminated  the 
feature  reflecting  results  of  an  evaluation  back  into  the  original  code.  Also,  a 
mode  was  added  that  allowed  the  programmer  to  attach  conditions  to  parts  of  the 
program  which  would  stop  execution  when  and  if  a condition  was  false.  This  is  es 
far  as  MUMBLE  ever  progressed,  and  it  was  not  in  use  as  of  the  time  of  the 
proposal  for  the  current  work. 


L2  MEND 

After  the  MDL  compiler  became  operational  and  many  additional  new 
software  features  became  available,  it  appeared  that  it  would  be  possible  to 
design  and  implement  a debugging  system  that  would  be  comprehensive,  eesy  to 
use,  and  reasonably  fast  It  was  thwefore  proposed  that  a debugging  system  for 
MDL  called  MEND  (Mdl  Executor,  sNslyzer,  and  Debugger)  be  designed  end 
implemented.  It  has  the  following  characteristics.  (A  glossery  of  special  terms. 
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tho*«  in  all  capital  lattars,  uaad  hara  and  throughout  tha  raat  of  thia  mamo  may  ba 
found  in  Appendix  B.) 

1.  MENO  possastas  a display  similar  to  that  of  MUMBLE,  including  tha 
raplacamant  of  argumants  in  a FORM  t^  thair  vaiuas  as  thay  ara  avMuatad. 

Z Exacution  is  monitorad  from  anothar  procass  <as  opposad  to  baing 
simulatad  as  in  ESP)  using  ISTEP  and  ralatad  faaturas*. 

3.  Exacution  speed  is  variable  by  tha  user  including  a static  single  or 
multi'Stap  mode  where  desired. 

4.  MEND  allows  execution  to  run  freely  below  a certain  depth  of 
evaluation  or  between  certain  points  in  tha  program  and  to  run  controlled 
elsewhere. 

5.  Unconditional  and  conditional  breakpoints  ara  available  that  can  ba 
attached  to  any  object  to  halt  exacution  before  evaluation  of  that  object 

6.  The  system  is  capable  of  keeping  track  of  programmer  specified 
conditions  and  of  changing  modes  or  giving  some  visible  indication  when  the 
conditions  are  met  (or  not  met). 

7.  Information,  such  as  the  local  values  of  programmer  specified  ATOMs 
and  the  values  of  programer  spedfiod  FORMs,  is  constantly  displayed  beneath  the 
main  display. 

8.  Each  line  in  the  main  display  area  is  A-printed  (abbreviated  printing, 
see  glossary)  and  can  be  viewed  in  full  at  any  time. 

9.  At  any  time,  with  execution  stop^  the  user  can  EVAL  objects  in  the 
ENVIRONMENT  of  the  program.  TNs  means  the  user  can  examine  the  state  of  the 
program  or  change  it 


13  Possible  Additional  Characteristics 

Certain  other  characteristics  were  seen  as  desirable  for  MENO  but 
possibly  beyond  the  scope  of  this  project  If  time  permitted  these  features  were 
to  be  included  in  the  system: 

1.  The  IMLAC  (see  section  HI)  multi-screen  capability  would  be  used  to 
allow  the  user  to  rapidly  switch  betwaen  the  debugger  display  and  the  program's 
own  output  Other  system  output  could  also  be  put  on  addiUond  pages. 

2.  The  editor  IMEO  (an  editor  for  MOL  objects  analogous  to  IMEOiT*)  would 
be  tied  into  the  system  to  allow  easy  editing.  PRINTTYPE  and  REAO-TABLEs 
would  be  used  to  allow  braakpoints  to  be  easily  set  and  removed  in  IMEO  as  single 
symbols.  Other  control  codes  and  statements  could  also  be  Inserted  using  tNs 
editor. 

3.  At  the  applications  programmer's  option  and  within  certain  limits, 
execution  could  be  reversed  either  so  that  sometNng  different  could  be  tried  or 
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for  purposes  of  reexamining  the  process  for  something  that  may  have  been  missed 
the  first  time.  This  feature  could  come  in  two  possible  forms,  the  UNDO  package 
to  actually  reverse  execution  or  a simulation  displaying  information  previously 
stored  by  the  system. 


1.4  Design  and  Implementation 

MEND  was  designed  with  the  intent  of  providing  the  application 
programmer  with  many  options  so  that  debugging  could  proceed  in  the  most 
suitable  manner  for  each  situatioa  In  the  normal  running  state,  MEND  dittplays 
several  kinds  of  information  on  the  screea  Most  important  is  an  area  showing  the 
execution  of  the  application  program  being  debugged  in  stack  form.  The  only  other 
area  that  is  always  present  is  a line  or  two  of  status  information  about  the  current 
operation  of  MEND  showing  its  current  speed  of  execution  (user  adjustable)  and 
the  state  of  each  modifiable  mode. 

It  was  intended  that  the  output  of  the  application  program  be  saved  by 
MEND  for  later  reference.  The  user  of  MEND  could  then  elect  to  have  the  most 
recent  output  constantly  displayed  in  a window  on  the  main  screen  (see  section  on 
future  work).  If  multi-screening  were  available,  the  output  could  be  kept  on 
another  virtual  screen.  That  screen  could  be  displayed  or  made  invisible  at  the 
user’s  option  without  stopping  MEND. 

Information  such  as  programmer  specified  values  of  ATOMs,  structured 
objects,  and,  in  general,  the  value  of  any  MOL  expression  may  be  constantly 
displayed.  MEND  is  also  capable  of  displaying  such  information  on  an  exception 
basis  according  to  some  predescribed  conditioa  Such  information  is  &-printed  but 
is  viewable  in  full  when  desired. 

It  is  important  for  a debugging  system  like  MEND  to  be  compatible  with 
and  to  take  advantage  of  available  software  in  related  areas.  Orte  such  area  is 
editing.  There  were  two  MDL  editors  in  use  when  the  proposal  for  tNs  work  was 
made,  EDIT"  and  IMED.  The  main  difference  between  them  is  that  IMED  uses  the 
local  editing  features  of  the  IMLAC  wNIe  EDIT  does  not  EDIT,  however,  has  the 
advantage  of  being  the  only  one  that  possesses  breakpoint  capabilities. 
Whichever  proved  to  be  most  compatible  with  MEND  (possibly  both)  would  be 
slightly  modified  to  allow  the  setting  and  removing  of  certain  MEND  codes  including, 
in  the  case  of  IMED,  breakpoints. 

MDL  itself  has  many  features  that  graatly  aid  the  debugging  process.  One 
of  these  is  FRAMES.  TNs  function  can  be  used  to  print  the  stack  of  functional 
evaluations  and  applications  when  execution  is  halted  at  any  depth  below  the  top 
level.  At  tNs  point  it  is  also  possible  to  get  the  values  of  objects  in  the  current 
ENVIRONMENT  and  to  change  them.  One  can  evan  restart  execution  et  a Ngher 


Uvd  after  making  such  changat.  Bacauaa  the  MDL  debugging  faaturat  are  quite 
powerful,  MENO  waa  designed  to  allow  the  user  to  stop  execution  (of  the 
application  program)  and  to  use  these  aids  or  any  others  built  in  to  MOL  with  the 
MENO  system  itself  transparent  Evaluation  would  taka  place  in  the  ENVIRONMENT 
of  the  application  program. 

MENO  now  includes  the  main  features  of  all  the  detx^ers  that  have  been 
mentioned  and  enough  other  features  that  it  should  prove  to  be  quite  useful  for 
the  analysis  and  debugging  of  MDL  programs.  It  should  also  serve  as  a good 
example  of  the  type  of  debusing  system  that  can  be  built  around  an  applicative 
type  language. 
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II  Tf  minal  Dltplav 
ILl  IMLAC  Console  Program 

One  basic  concern  throughout  the  project  was  the  display:  how  the 
information  made  available  by  MEND  would  be  presented  to  the  user.  To  a large 
extent,  the  physical  characteristics  of  MDL,  ITS'^  (Incompatible  Timesharing  System, 
the  operating  system  used  on  the  Dynamic  Modeling  System  computer),  and  the 
evailable  terminals  dictated  what  was  reasonably  possible. 

The  terminal  most  commonly  used  by  users  of  the  Dynamic  Modeling 
System  is  the  IMLAC  PDS-1.  This  is  a minicomputer  capable  of  having  programs 
loaded  into  it  from  the  PDP-10  host  computer.  One  program  written  for  it  by 
Dave  Lebling  is  MSC,  a multiple-screen  terminal  program.  Up  to  four  virtual 
screens  (or  pages)  can  be  created  that  will  individually  operate  like  the  actual 
screen  area  of  the  standard  terminal  program  (SSV'^.  Output  may  be  directed  to 
any  one  of  the  screens  and  any  screen  may  be  visible  or  invisible  at  any  instant  of 
time,  at  the  programmer’s  optioa  Selection  of  screen  is  controllable  either  by 
\ program  from  the  host  or  locally  by  the  user. 

It  was  originally  intenM  that  MEND  would  use  MSC  for  its  normal  display. 
One  page  would  constantly  show  MEND’S  representation  of  the  control  stack  of  the 
application  program.  Output  initiated  by  the  program  being  debugged  would  go  to 
a second  page.  A third  page  would  be  used  for  interaction  with  MEND  and  would 
show  user  typein  along  with  any  output  from  MEND  that  one  was  interested  in 
seeing.  The  latter  would  include,  by  user  request,  full  displays  of  both  objects 
printed  in  an  abbreviated  form  on  the  page  containing  the  control  stack  of  the 
application  program  and  values  being  monitored  or  traced.  The  user  could  switch 
back  and  forth  among  the  pages  at  will  during  the  execution  of  the  program  The 
application  program  would  have  a full  standard  screen  to  write  onto,  and  ample 
room  would  be  available  for  the  information  to  be  displayed  by  MEND. 

After  a fair  amount  of  testing,  this  proposal  was  discarded  for  the 
following  reasons.  First,  MSC  was  supposed  to  look  just  like  SSV  for  individual 
virtual  screens.  Unfortunately  new  features  added  to  SSV  had  not  also  been 
added  to  MSC.  A primary  reason  for  this  disparity  was  that  the  new  features 
encroached  upon  the  IMLACs  character  space.  An  SSV  with  all  current  features 
can  only  hold  about  one  and  a half  full  pages  of  text,  where  a page  Is  the  amount 
that  can  be  visible  at  one  time.  The  overhead  reared  for  additional  screens 
reduces  it  still  further.  Therefore,  with  all  features  included,  four  virtual  screens 
could  each  only  average  about  one- third  full.  Without  many  of  the  current 
j;  features,  people  were  reluctant  to  use  MSC 

|j  The  second  and  perhaps  most  devastating  problem  with  MSC  is  that  it  is 

not  properly  supported  by  ITS  as  is  SSV.  Ordinarily  the  operating  aystem  will 
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kMp  track  of  whart  on  tho  paga  tha  tarminal’t  cursor  Is  and  will  propariy  handia 
such  updating  as  dalations  avan  in  tha  faca  of  random  accass  parformad  (if  dona 
by  raquast  to  tha  systam).  Whan  using  MSC,  ITS  doas  not  raaliza  that  Information 
is  baing  written  onto  more  than  one  screen  and  will  therefore  often  move  tha 
cursor  to  tha  wrong  positioa 

MEND  could  completely  control  positioning  for  typaout  and  echoing  on 
typain  but  that  would  add  tha  large  overhead  of  having  to  run  a non-triviai  routine 
for  each  character  typed  out  on  the  display.  Also,  because  MSC  is  not  tha 
standard  console  program,  requiring  tha  user  to  load  it  before  using  MEND  might 
discourage  tha  use  of  ME^.  (It  takas  between  about  30  seconds  and  a couple  of 
minutes,  depending  upon  system  load,  to  load  a new  console  program  into  the 
IMLAC.) 

From  the  outset  it  was  intended  that  MEND  ba  used  routinely  by 
programmers  as  debugging  problems  arose.  Therefore  it  was  decided  that  the 
proper  way  for  such  a system  to  operate  was  to  use,  as  far  as  possible,  tha 
common  environment  so  as  to  keep  the  overhead  for  invoking  MEMO  small.  TNs 
philosophy,  which  had  been  seen  to  affect  the  success  of  many  earlier  projects, 
decided  between  the  alternatives  and  in  tNs  case  led  to  the  final  decision  to  use 
SS^'  instead  of  MSC. 


11.2  Terminal  Independence 

The  MEND  terminal  handling  capabilities  are  actually  quite  general  and 
MEND  does  not  depend  exclusively  on  SSV.  For  the  purpose  of  dividing  the 
screen  area  into  several  sections,  horizontal  lines  are  sometimes  drawn  (see 
Appendix  A showing  sample  display).  With  an  IMLAC  and  SSV  these  lines  could  be 
drewn  quite  simply  using  graphic  mode.  However,  for  purposes  of  generality  with 
regard  to  terminals,  these  lines  are  instead  form^  by  using  underbar  characters 
(on  a line  of  their  own).  By  using  no  actual  grapMcs  MEND  can  be  used  with 
almost  any  display  terminal  having  random  access.  MEND  outputs  display 
commands,  such  as  clearing  a line,  as  escape  codes  to  ITS  which  ^hen  translates 
these  into  the  appropriate  commands  for  tha  tarminal  in  use.  ITS  currently  knows 
about  several  types  of  display  terminals  in  use  at  the  Laboratory  for  Computer 
Sdenee,  and  otfm  types  of  tenninals  located  at  foreign  sites  on  the  ARPA  network 
may  be  handled  by  Interface  software  that  simulates  a known  type.  Naturally 
ME^  can  handle  a large  range  of  possible  line  and  screen  lengths.  (The  curreM 
version  of  SSV  provides  four  possible  character  sizosi) 


•»  afc.. 


11.3  Control  of  Screen  Sectioning 

There  still  remained  the  question  of  how  to  handle  the  multi-sectioning  of 
the  displayed  information.  Originrily  three  sections  corresponding  to  the  three 
virtual  screens  in  the  aborted  MSC  implementation  were  planned.  The  bottom 
section  would  hold  user  typein  and  application  program  output  Three  possible 
methods  of  achieving  tNs  involved  having  ITS,  MOL,  or  MEND  do  various  amounts  of 
the  work  with  increasing  overhead  and  decreasing  speed  for  those  three, 
respectively. 

The  most  attractive  solution  utilized  an  ITS  feature  allowing  the 
specification  of  an  echo  area  at  the  bottom  of  the  screen  where  echoed  input 
would  aiways  be  printed  (with  the  echoing  handled  by  the  systenv  wNch  is  the 
normal  case).  After  some  experimentation  this  method  of  handing  the  typein  and 
application  program  output  was  rejected  because  typeout  and  deletion  are  handled 
MOL  which  ignores  the  echo  area  MEND  would  effectively  have  had  to  control 
all  typeout  and  monitor  all  typein,  wNch  would  have  made  the  echo  area  useless. 

Experimentation  with  the  second  solution^  an  indirect  method,  involved 
monitoring  of  special  MDL  memory  locations  where  information  concerning 
horizontal  and  vertical  page  positions  is  stored  It  was  soon  discovered  that  MOL 
becomes  confused  quickiy,  contains  several  bugs  with  respect  to  this  position 
information,  and  generally  has  a poor  idea  of  whera  it  is  actually  printing. 

The  tNrd  solution  appeared  to  be  the  most  painful  from  an  implementation 
and  erficiency  point  of  view.  MEND  would  need  to  control  the  printing  of  every 
character  on  output  and  certain  characters  on  input,  constantly  checking  page 
positions  by  querying  the  system.  Not  only  did  this  slow  output,  but  also  MENO 
was  forced  to  constantly  move  the  cursor  to  a safe  position  in  case  MDL  managed 
to  sneak  some  output  past  it,  wNch  it  occasionally  does. 

Fortuitously  the  problem  was  neatly  solvad  when  a little  known  feature  of 
ITS  was  (fiscovered  It  is  possible  to  open  a channel  to  the  terminal  in  a mode  that 
would  cause  all  output  to  appear  in  the  echo  area  By  creating  tNs  echo  area  and 
reopening  MDL’s  normal  terminal  output  channel  in  this  mode,  it  is  possible  to 
cause  MDL  and  the  application  program  to  tNnk  that  the  entire  screen  consists  of 
only  the  echo  area.  Ali  output  including  application  program  display  escape 
commands  is  automatically  routed  by  ITS  to  tNs  echo  area  MEND  sends  its  output 
to  a second  channel  opened  in  the  normal  mode,  thereby  allowing  it  to  use  an  area 
of  the  screen  unknown  to  and  loft  untouched  by  the  application  program.  The 
physical  cursor  stays  where  the  last  used  logical  cursor  left  it,  thereby  eliminating 
most  of  the  unnecessary  cursor  movement,  resulting  in  a more  pleasing  visual 
effecL 

As  a result  of  tNs  solution,  the  screen  is  divided  into  only  two  main 
sectiona  All  typein  appears  in  the  iowar  sactiors  whether  it  is  to  the  application 


program  or  to  MEND.  Application  program  output  aiao  gooa  to  tho  lowor  aoctioi\ 
at  doaa  unatructurad  output  produead  by  intaraction  with  MEMO.  Tho  uppor 
aoctiofs  in  gonaral,  contains  only  thoaa  itoma  that  occupy  ena  Hno  of  tho  daplpy 
oacK  At  will  bo  oxpiainod  lator,  thoao  itoma  indudo  all  output  automotically 
diaplayod  by  MEND  during  oKocuUon  of  tho  ippHcotion  program. 


! 

i 

'Ml 


15 


HI  MSTACK;  MEND*s  Repfentatton  of  th»  Control  Stack 
III.1  Program  Execution  in  MDL 

MEMO’S  primary  role  is  to  allow  the  applications  programmer  to  visually 
monitor  the  execution  of  a program.  In  a language  like  MDL,  this  is  most  easily 
accomplished  by  showing  the  programmer  a "pictura"  of  tha  control  stack. 

A MOL  program  consists  of  the  avaluation  of  a singia  object  Tha  object 
it  usually  structured  in  some  manner  and  itself  contains  other  objects.  The  most 
common  object  is  the  FORM.  This  is  a list  of  objects  in  which  the  first  la  (or 
evaluates  to)  some  function  and  the  rest  are  arguments  to  that  function.  A FORM 
is  evaluated  by  applying  the  function  to  its  arguments,  usually  after  the  arguments 
are  themselves  evaluated.  This  evaluation  actually  ia  initiated  by  the  MOL 
interpreter  by  applying  the  function  EVAL  to  tha  original  object  EVAL  takes  an 
object  as  its  argument  and  returns  tha  value  to  which  it  evaluates. 

Figure  1 shows  a (simplified)  static  representation  of  the  avaluation  of  a 
MOL  object  Starting  with  the  FORM  (list  of  objects  in  angle-brackets)  to  be 
evaluate  the  flow  of  control/evaluation  rMQf  be  described  as  a depth-first  search 
through  the  tree  pictured.  The  arrows  raprasent  values  being  returned  to 
previous  levels.  At  the  end  of  tNs  "search*  the  FORM  returns  the  value  shown  at 
the  top. 
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Typically  tha  control  stack  will  start  with  one  object  on  it,  the  FORM  to  be 
evaluated.  TNs  evaluation  will  first  requira  that  the  objects  in  the  FORM  (possibly 
FORMS  themselves)  be  added  to  tha  stack  and  evaluated.  EVAL  recursively  calls 
itself  for  tNs  purpose.  The  stack  builds  (downward;  by  convantion)  until  some 
object  is  placed  on  it  wNch  is  known  by  EVAL  to  need  no  further  evaluetion.  TNs 
object  is  returned  as  its  own  valua  to  the  previous  level  and  values  continue  to 
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b«  r*turn«d  upward  until  a laval  it  raaehad  whara  anothar  objaet  muat  ba 
avaluatad.  in  tNt  mannar  tha  atack  powa  and  ahrinka  until  tha  topmaat  (initial) 
object  raturna  a value. 


IIL2  Monitoring  Program  Execution 

Tha  mannar  in  wNch  tha  atack  builda,  tha  objacta  are  avaluatad,  and  tha 
valuat  are  ratumad  iiluatrata  moat  of  what  tha  program  ia  doing  Other  factora, 
including  aide  affacta  and  compilad  coda,  will  ba  diacuaaad  at  tha  and  of  tNa 
chapter.  MENO’a  main  diapiay  U^afora  ahowa  a rapraaantaticm  of  tha  atack  being 
continuoualy  updated  aa  axacution/avaluation  proca^ 

Thera  are  eaaantially  two  waya  that  MEND  could  follow  tha  flow  of  control 
of  tha  application  program.  Tha  moat  Jract  way,  aa  attempted  by  MUMBLE'  and 
diacuaaad  in  tha  laat  chapter,  would  ba  for  MEND  to  axacuta  tha  application 
program  by  aimulating  tha  operation  of  MOL.  TNa  type  of  aimulatien  haa  bean 
ahown  to  require  a complex  and  ail  too  often  fragile  atruetura.  Tha  debugging 
program  would  need  to  ba  conatantly  updated  to  match  changaa  and  additiona  to 
tha  MDL  language,  but  more  importantly  it  would  fail  to  properly  handle 
programmar-dafinad  primitivaa,  aavaral  variatiaa  of  which  are  provided  for  by 
MDL 

A far  more  aatiafactory  method  ia  to  allow  MOL  to  axacuta  tha  application 
program  in  more  or  ieaa  ita  normal  faahion  but  to  atand  back  aomawhara  and 
watcK  Fortunately  MDL  containa  a machaniam  ideal  for  tNa,  callad  multiprocaaaing 
Baaicaiiy  anothar  control  atack,  or  procaaa,  may  ba  created  (independent  of  tha 
firat)  that  may  ba  used  to  execute  a cRffarant  function  with  ita  own  aat  of  variabia 
bindinga.  One  auch  procaaa,  in  tNa  caaa  MEND,  may  place  anothar,  tha  application 
program,  into  a aingta  atap  mode  whara  tha  latter  v^ll  ba  atoppad  before  each  call 
to  EVAL  and  again  aa  each  call  raturna.  Tha  MEND  procaaa  vrill  at  thaaa  pointa  ba 
raatartad  and  given  information  about  what  tha  application  procaaa  ia  doing  MEND 
atoraa  tNa  information  in  a multi-level  atruetura  it  craataa  callad  an  MSTACK. 

Each  lava!  of  an  MSTACK  corraaponda  to  a level  of  tha  control  atack  being 
monitored.  Each  level  containa  tha  original  object  (actually,  a pointer  to  it)  being 
evaluated  at  that  level  and  a new  object,  callad  tha  "diaplayad  object”,  that  will  or 
doaa  contain  tha  raaulta  of  evaluating  a^  of  tha  argumanta  or  alamanta  of  tha 
original.  Tha  diaplayad  object  ia  iNtially  tha  aama  aa  tha  original  (In  a real  aanea, 
It  ia  tha  original)  but  ia  ayatamatically  rebuilt  aa  each  alamant  ia  avaluatad  and 
replaced  by  what  it  raturna.  Thua  MEND  can  keep  track  of  tha  ralationahip 
between  tha  changing  diaplay  and  tha  unchanging  programi  (Figure  2 ahowa  tha 
varioua  atagaa  that  tha  diaplayad  objaet  corraaponding  to  tha  FORM  being 
evaluotad  in  Rgura  1 ^aa  througK  Each  ataga  would  In  fact  be  painted  ever  the 
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previout  one  to  that  alt  of  theta  ttaget  repretent  only  one  line  of  the  tcreea 
The  down-arrow  thown  in  toma  of  the  ttagat  it  a place-holder  that  repretenta  an 
object  that  it  actually  expandad  on  the  next  line  of  the  tcreea)  A pointer  it  alto 
kept  thowing  which  element  it  currently  above  tNt  on  the  ttack  to  be  evaluated 
unleta,  of  courte,  tNt  it  the  iNtial  element  of  the  ttack. 
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Figure  2 


1113  A Displayed  Repratantation  of  Proiram  Execution 

The  printed  repretentation  of  the  ttack  occupiot  the  top  section  of  the 
screen  and  it  the  most  prominent  and  important  characteristic  of  MEND.  Mott 
ofton^  in  fact*  it  it  oNy  necettary  to  watch  tNt  ditpiay  at  the  appiication  program 
it  executed  to  ascertain  where  a bug  it  located  or  to  observe  exactly  how  the 
program  oporatat.  Therefore  contidorabla  time  hat  bean  spent  making  the 
operation  of  the  MSTACK  and  attociatad  ditpiay  at  natural  and  informative  at 
pottible. 

Uting  the  colloctad  information  dotcribod  in  the  previous  section,  a 
representation  of  the  stack  is  displayad  as  a number  of  linos,  each  corresponding 
to  one  level.  Each  line  shows  a level  number  and  the  displayed  object  printed  In 
an  abbreviated  form  (known  as  "A-printin^,  named  for  the  printing  function  A'* 
created  by  Greg  Pfister).  Although  strictly  speaking  the  stack  builds  upward 
(towards  Ngher  memory  locations),  it  seems  mere  natural  to  display  and  apeak  of 
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th«  stack  at  building  from  the  top  downward^  in  tha  diraction  that  printing  normally 
occurs.  As  aach  alamant  of  tha  bottom  laval  (tha  bottom  lino  on  tNs  taction  of 
tha  scraan)  is  placad  on  tha  stack  for  avaluation,  a naw  lina  is  addad  banaath  tha 
previous  bottom-laval  lina  showing  that  alamant,  and  tha  alamant  is  raplacad  in 
tha  pravious  iina  by  a pointar  ("f”)  marking  its  locatioa  Whan  tha  alamant  finally 
returns  a value,  tha  raturnad  valua  will  rapiaca  tha  pointar  in  tha  displayad 
objact 

To  avoid  visual  distractlorv  a minimum  of  updating  is  dona  on  tha  scraaa 
In  most  casas  random  accost  is  usad  to  rapiaca  only  thosa  linos  that  hava  changad. 
In  ganaral  tha  complata  stack  will  not  fit  in  tha  dismay  araa  allocatad  for  it  (whose 
size  it  user  adjustable)  so  a scrolling  procadura  hM  boon  davisod.  Tha  complata 
display  araa  is  rewritten  whanavar  an  attempt  is  made  to  write  past  tha  bottom 
or  arata  upward  past  a certain  laval  while  soma  Unas  are  invisibla  because  they 
hava  bean  scrollad  off.  Tha  scrolling  paramatars  hava  bean  salactad  to  optimize 
tha  number  of  lines  visibla  on  tha  average  vs.  tha  frequency  of  scrolling.  Level 
numbers  allow  tha  user  to  sea  how  much  is  hidden  "above  tha  scraan"  and  how 
deep  tha  avaluation  is  nested 


III.4  MEMO  Program  Steps  Vs.  MOL  Steps 

To  make  it  easier  for  tha  programmer  to  follow  what  tha  application 
program  is  doing,  the  speed  of  execution  of  tha  program  must  be  controllable. 
MEND  does  this  by  inserting  a constanL  user  adjustabla  delay  between  program 
"steps."  One  MEND  step  is  not  pradsaly  tha  same  as  one  MOL  step.  Ramambar 
that  a MOL  step  is  one  call  to  or  return  from  EVAL.  Each  MSTACK  laval,  and 
therefore  aach  displayad  lina,  will  have  two  MOL  steps  associated  with  it  At  tha 
first  step,  MEND  will  create  tha  laval  and  add  one  lina  to  tha  screen.  At  the 
second  step,  MENO  will  erase  that  lina  and  put  tha  returned  value  back  into  the 
previous  line.  For  clarity  MENO  adds  a third  step  between  these  two  which 
actually  occurs  at  tha  second  MOL  step.  Before  substituting  into  tha  previous  line, 
the  currant  one  is  first  raplacad  by  tha  returned  value,  tha  normal  delay  occurs, 
and  than  tha  "second"  step  occurs  as  described 

Soma  types  of  MOL  objects  are  salf-avaiuatinc  EVAL  will  simply  return 
the  object  it  was  givea  Although  nothing  interesting  has  happened,  two  steps 
have  occurred  In  tNs  case  MENO  will  avoid  dutter  by  pretending  that  no  steps 
have  occured  (MENO  oNy  does  tNs  with  built-in  types  that  MEND  recogNzea,  and 
the  programmer  should  recognizor  as  being  self-evaluating  Programmer-defined 
types  that  are  self-evaluating  wW  ganarate  tha  usual  number  of  MENO  steps.) 

Another  case  of  disparity  between  MOL  and  MEND  stops  is  more  compleK. 
First  some  further  explanations  about  MOL  objects  are  needed  Generally  the 


1 

; 

i 


■i 


I 


19 


intaretting  objects,  the  ones  that  generate  MEND  atepa,  are  linear  (usually  list) 
atructures  containing  a numbar  of  other  MDL  objects,  as  are  the  FORMs  described 
earlier.  Normally  during  evaluation  of  such  an  object  the  elements  will  be 
evaluated  one  at  a time  from  first  to  last  However  tNs  sequence  is  not  always 
followed  by  MOL  MEND  cannot  directly  determine  which  element  is  about  to  be 
evaluated  at  each  call  to  EVAL  It  is  oNy  given  the  object  to  be  evaluated  itaelf 
and  not  its  position  in  the  parent  structure.  It  is  normally  sufficient  to  do  a 
comparison  of  tNs  object  with  the  elements  of  the  parent,  starting  with  the  first 
element  believed  to  not  yet  have  been  evaluated.  Naturally,  if  the  elements  are 
evaluated  out  of  order,  tNs  procedure  may  fail  to  find  the  (tosired  match,  because 
a MDL  object  may  contain  the  same  element  in  two  or  nwre  positions.  Thus  it  is 
possible  to  match  the  about-to*be-evaluated  object  to  the  wrong  occurrence  of  it 
Further  complications  arise  because  some  functions  can  aometimes  back  up  and 
re-evaluate  their  arguments. 

A strong  attempt  was  mada  to  make  MEND  dependent  only  upon  the 
general  characteristics  of  MDL  functions  and  not  upon  specific  exceptions  and 
idosyncracies.  It  was  felt  to  be  desirable  to  make  MEND  independent  of  both 
future  changes  to  the  language  and  programmer-defined  "primitives*  that  would 
not  be  known  to  MEND.  Besides,  without  actually  simulating  MOL  it  la  not  possible 
to  always  get  the  information  MEND  needs.  It  was  felt  that  the  "general  rule” 
approach  would  take  care  of  a sufficiently  large  number  of  cases  without  felling 
into  the  simulator  problem. 

It  was  determined  after  some  experimentation,  however,  that  MEND  could 
not  be  made  to  work  properly  without  some  specific  knowledge  about  several 
important  cases  in  MDL  Two  functions,  PROG  and  REPEAT,  allow  for  brancNng  the 
flow  of  control.  They  are  normally  first-to-last  functions  as  described  sbove  but 
at  times  control  may  jump  backwards  to  re-evaluate  some  elements.  MEND  was 
implemented  so  that  if  it  cannot  locate  an  element  in  its  normal  search  path,  it  will 
start  looking  again  from  the  beginNng  of  the  structure.  If  it  la  then  found,  the 
displayed  object  will  be  reiNtialized  to  be  as  if  evaluation  had  not  yet  proceeded 
peat  Uwt  point  Evaluation  will  then  continue  normally. 

Another  phenomenon  of  MDL  that  we  must  discuss  la  what  this  author 
labels  the  "clause”  behavior.  A clause  is  a list  of  objects  given  to  a function  as  a 
single  ergumenL  The  list  is  not  itself  evaluatecA  but  some  or  all  of  ita  elements 
are  evaluated.  The  most  common  function  illustrating  tNs  behavior  is  CONO,  a 
general  purpose  conditional  function.  CONO's  arguments  are  all  lists  of  objects.  It 
sequences  through  these  lists,  evaluating  the  first  object  in  each,  until  an 
evaluated  object  returns  sometNng  considered  "true."  Then  the  rest  of  the 
objects  in  that  list  are  evaluated  and  OOND  returns  what  the  last  object  in  the  Hat 
retumsi  MEND’S  normal  search  path  only  looks  at  top-level  elements  and  would 
therefore  never  find  the  ones  actually  being  evaluated 


TN»  ph«nofn«non  tMincd  to  bo  more  widotpread  than  the  PROG/REPEAT 
one  end  could  not  be  easily  attributed  to  certain  functions.  The  solution  chosen 
here  wes  to  in  all  cases  do  a nested  search  in  elements  that  looked  as  if  they 
might  be  clauses.  (The  search  actually  goes  one  extra  level  deep  to  allow  for 
certain  special  cases.)  When  a match  is  found  in  a douse,  MEND  will  for  darity 
generate  extra  steps  to  make  it  appear  to  the  user  as  if  first  the  clause  and  then 
its  appropriate  element  was  put  on  the  stack  for  evaluation  The  clause  will  stay 
on  the  stack  until  some  element  that  is  net  above  it  in  the  evaluation  tree  is 
evaluated  At  that  time  the  clause  will  be  removed  in  an  orderly  manner,  and  the 
new  element  or  clause  plus  element  will  be  put  onto  the  stack.  To  do  this 
smoothly,  up  to  six  MEND  steps  may  hove  to  be  generated  for  the  one  MOL  step. 
(See  the  example  in  Appendix  A.) 


IIL5  Whet  the  User  Does  Not  See 

MEND,  in  its  display  of  the  MSTACK,  attempts  to  show  the  user  everytNng 
of  importance  that  is  happening  as  the  program  is  executed.  However  certein 
feetures  of  MOL  cannot  be  captured  in  tNs  sort  of  representatioa 

One  such  feature  is  the  existence  of  compiled  code.  Although  MOL  was 
originally  intended  to  be  a Ngh-level  interpretive  language,  an  assembler  was 
wrlttan'^  produdng  machine  code  that  executes  in  the  MOL  environment,  to  allow 
programmers  to  create  "primitives"  that  perform  functions  not  otherwise  availabie 
in  MOL  Once  the  assembler  was  writterv  it  was  natural  that  a compiler'*  followed 
It  translates  normal  MOL  code  into  MOL  assembly  code  which  is  then  assembled 
Typically  MOL  programs  are  tested  interpretively  and,  when  fully  debugged, 
compiled  in  order  to  obtain  a major  increase  in  speed  of  execution. 

A cell  to  a compiled  (or  assembled)  function  usually  looks  to  the 
progremmer  end  to  MENO  like  a call  to  a MOL  primitive.  The  operation  of  the 
function  is  not  seen  except  when  it  calls  uncompiied  functions.  This  does  not 
present  a major  problem  to  MENO  since  generally  only  uncompiled  functions  are 
being  debugged,  end  the  compiled  ones  encountered  ere  hopefully  performing 
kno¥im  functions  properly. 

One  feeture  of  MOL  thet  MENO  Is  uneWe  to  cope  with  is  the  interrupt 
system.  The  progremmer  mey  eneble  e large  dess  of  interrupts  end  essign 
himdling  functions  wherever  <Mred  Examples  indude  interrupts  for  cheracters 
being  typed  to  e certain  input  channel  and  notification  that  the  system  is  about  to 
be  brought  down  (MEND  uses  interrupts  to  catch  single  character  commands  and 
to  catch  errors.) 

Recall  thet  MENO  monitors  appNcetlen  program  OKOCution  by  pladnf  Its 
process  Into  e single^topping  mode.  Whan  MOL  passes  contrd  to  an  interrupt 
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handler,  it  temporarily  caueee  the  procett  to  leave  aingle-atepping  mode.  This  la 
neceatary  partially  because  such  a handler  may  be  specified  to  run  in  a process 
other  than  the  current  one  at  the  time  of  the  interrupt  It  unfortunately  maikes  the 
handler  invisible  to  MEND,  it  is  therefore  not  currently  possible  to  use  MEMO  to 
debug  interrupt  handlers. 

There  is  a whole  series  of  side-effects,  such  as  printing  by  the  application 
program,  that  are  not  directly  seen  in  the  MSTACK  representation  but  are  made 
visible  by  various  other  features  of  MEND.  These  will  be  discussed  where 
appropriate  in  later  sections. 


IV  l^^u^ng  CofwnKndt  to  MEND 


IV.  1 Typ««  of  CofiNiiondo 

Thore  it  • nood  in  debugging  tyttemt  timilar  to  MEND  for  two  types  of 
commands  for  controlling  operatioa  One  type  is  a set  of  short,  immediate-action 
commends  that  the  user  of  the  debugging  system  may  issue  at  any  time,  such  as  a 
command  to  completely  stop  all  activities  of  the  debugging  system  e^  to  exit 
The  other  type  is  the  set  of  all  commands  not  belonging  to  the  first  sot.  This 
includes  commands  that  take  arguments  and  those  that  can  only  be  given  while  the 
application  program  is  suspended  from  executioa 


IV.2  Immediate  Interrupt-Level  Commands 

In  MEND'S  normal  mode,  various  actions  occur  automatically.  Most 
importantly,  the  application  program  is  executing  and  the  displayed  representation 
of  the  MSTACK  is  being  updated  correspondingly.  During  tNs  time  the  programmer 
may  type  ahead  to  the  application  program,  but,  since  there  is  only  one  physical 
cursor  that  is  used  by  both  MEND’S  display  and  typein  echoing  that  must  timrefore 
jump  back  and  forth  between  the  two  text  entry  positions,  a large  amount  of 
typein  is  awkward  Therefore,  all  immediate  action  commands  that  the  user  can 
issue  while  MEND  is  in  automatic  mode  are  single  characters.  To  minimize  the 
chance  of  conflict  with  typein  that  the  executing  application  program  might  read, 
MEND  immediate  action  commands  are  invoked  by  typing  certain  ASCII  control 
characters.  Furthermore  typing  one  of  these  control  characters  causes  an 
interrupt  to  occur  which  is  hsndled  by  MEND  and  allows  immediate  response. 

Note  that  tNs  arrangement  requires  that  there  be  certain  reserved 
characters,  as  iisted  below,  that  cannot  be  used  to  communicate  with  the 
application  program.  Normally  tNs  presents  no  difficulty.  An  alternative  method 
was  considered  that  required  the  reservation  of  oNy  one  control  character. 
However,  the  user  would  be  required  to  type  an  additional  character  as  an 
argument  sigNfying  what  function  is  intended  There  dki  net  seem  to  be  e great 
advantage  to  this  scheme  and  it  was  considered  after  the  first  scheme  had  been 
implemented.  For  this  and  other  reasons  stated  later  in  this  section,  the 
alternative  scheme  was  discarded 

From  the  user’s  viewpoint,  the  currently  implemented  interrupt-level 
commends  are  as  follows.  (ASCII  control  characters  are  represented  by  "T* 
followed  by  the  correspondbig  letter.) 


23 


TL  clear  screen,  reprint  steck  end  input 

TQ  Quit  from  current  MEND 

TE  End  automatic  mode 

TB  Begin  automatic  mode 

TU  Unprint  (stop  displaying  stack) 

TP  Print  (start  displaying  stack) 

TO  skip  Over  (completely  evaluate)  current  object 

TN  Next  step  (used  when  not  in  automatic  mode) 

The  command  invoked  by  typing  TL  is  for  housekeeping  purposes.  It 
causes  extraneous  information  (e.g.,  old  program  output)  to  be  cleared  from  the 
screen  end  all  MEND-related  constantly-displayed  information  to  be  reprinted. 
Unread  input  is  also  reprinted. 

The  command  invoked  by  typing  TQ  is  used  to  exit  from  an  invocation  of 
MEND.  It  has  the  effect  of  stopping  all  actions  related  to  monitoring  the  application 
program  and  allowing  the  program  to  continue  normally.  In  this  way  a programmer 
may  discard  MEND  and  continue  running  the  application  program  without  the  need 
for  resterting  it  at  the  beginning. 

The  two  commands  invoked  by  typing  TE  and  TB  switch  MEND  between 
automatic  mode,  the  only  one  described  thus  far,  and  non-automatic  (command) 
mode.  Command  mode  will  be  described  in  the  next  section. 

Sometimes  it  is  desirable  for  the  sake  of  saving  both  computer  time  and 
the  epplication  programmer’s  time  to  turn  off  printing  of  the  MSTACK.  MEND  will 
continue  to  monitor  program  execution  and  store  the  appropriate  information  but  it 
does  not  display  It  Nor  does  it  pause  between  steps  In  the  normal  manner.  This 
is  mainly  useful  when  breakpoints  are  present  to  turn  on  printing  or  switch  to 
commend  mode.  At  that  time  MEND  will  know  how  It  got  to  the  current  level  and 
will  be  able  to  display  the  MSTACK  es  usual.  Two  commands  invoked  by  typing  TU 
and  TP  toggle  the  state  of  printing. 

Whenever  the  programmer  is  satisfied  that  a particular  call  of  a function  is 
working  properly  or  for  some  reason  he  or  she  is  not  interested  in  seeing  the 
details  of  evaluation  of  some  object,  typing  TO  just  before  the  object’s  evaluation 
invokes  e command  that  causes  MEND  to  skip  over  that  evaluation  and  continue 
normei  monitoring  and  display  immediately  after  a value  is  returned.  Unlike  turning 
off  the  printing,  no  monitoring  is  performed  here  at  all  so  the  evaluation  proceeds 
as  fast  as  it  would  without  MEND.  This  Is  actually  hartdled  by  causing  MDL  to 
leave  single-stepping  mode  during  the  evaluation  of  the  object 

The  lest  command,  invoked  by  typing  TN,  Is  specif  In  that  It  la  Ignored  in 
automatic  mode,  its  actions  In  commar^  mode  will  be  described  In  the  next 
section.  It  is  an  interrupt-level  command  mainly  for  convenience  and  compatibility 
with  OCBUGR. 
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Bruce  Daniels'  DEBUGR  is  the  prototype  MOL  multiprocessing  debugging 
system  It  provides  a simple  user  interface  to  MOL’s  single-stepping  functions  thet 
makes  single-stepping  through  a MOL  program  appear  similar  to  single-stepping 
through  an  assembly-language  program  with  DOT^.  The  choices  of  characters  for 
invoking  many  of  the  MEND  functions  were  based  upon  the  characters  used  to 
invoke  similar  functions  in  DEBUGR.  Many  of  DEBUGR's  command  invocation 
characters  were  in  turn  based  upon  those  in  DOT.  The  object  of  all  of  tNs  ia  to 
biald  character /command  associations  in  the  user’s  mind  that  may  be  carried  over 
from  one  system  to  the  next. 

Several  other  control -character  commands  are  handled  by  MEND  invisibly. 
That  la,  the  user  may  not  be  aware  that  they  are  being  handled  Most  of  these 
are  commands  that  are  already  being  handed  by  other  subsystems  but  must  be 
intercepted  by  MEND  to  maintdn  consistency  in  its  environment  Two  of  tNs  type, 
invoked  by  typing  tS  and  TG,  are  already  set  up  in  an  initial  MDL  and  a third, 
invoked  by  typing  TF,  is  set  up  by  the  subsystem  EDIT,  wNch  is  called  by  MEND  as 
described  in  the  next  section  All  three  of  these  are  used  to  escape  to  various 
command  levels.  MEND  has  its  own  command  level  (see  next  section)  and  must  in 
many  cases  escape  to  that  one  instead  to  maintain  control.  Until  a method  was 
discovered  for  having  ITS  section  the  screen,  it  was  necessary  to  also  interrupt  on 
carriage-returns  (TM,  the  new-line  character)  on  Input  to  Insure  that  typein  was 
kept  in  the  proper  section. 


IV.3  MEND'S  Command  Level 

Sometimes  the  user  may  wish  to  stop  the  application  program  at  some 
point  to  examine  it  in  more  detail  or  to  alter  it  or  its  environment  in  some  way. 
Alternatively  the  user  may  want  to  issue  commands  to  MEND  that  require 
arguments.  A command  level  is  provided  for  both  of  these  activities. 

The  command  level  differs  from  the  automatic  mode  described  in  the  last 
section  in  two  ways.  First,  the  application  program  is  not  continually  executing.  It 
runs  one  step  at  a time  under  the  direct  control  of  the  user  r'ather  than 
automatically.  Second,  in  non-autometic  mode  typein  is  normally  passed  to  MEND 
instead  of  the  application  program,  even  thet  dess  of  typein  which  does  not 
produce  immediate  actioa 

When  the  application  program  is  stopped,  the  user  may  either  request  a 
service  from  the  debugging  system  or  examine  and/or  modify  the  program  and/or 
its  environment  Since  editing  functions  form  a large  pert  of  the  latter  dess  of 
actions,  it  was  dedded  that  Instead  of  requiring  the  user  to  Import"  an  editor, 
MEND  should  provide  an  editor  by  maMng  one  available  at  commend  level. 

It  is  generally  believed  and  empirical  evidence  indketes  thet  creating  a 
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new  editor  is  "the  kiss  of  death"  for  a MOL  subsystem.  A number  of  MOL  editors 
have  been  tried  over  the  years  and  the  only  one  that  finally  became  generally 
accepted  (and  is  now  pre-loaded  in  MOL)  is  EOIT".  Members  of  the  MOL 
community  will  tolerate  minor  changes  to  EOIT,  but  they  will  not  accept  a new 
editing  system.  The  situation  is  analogous  to  one  of  the  major  obstacles  blocking 
the  acceptance  of  ESP.  Programmers  were  accustomed  to  using  DOT  to  examine 
and  modify  their  machine-language  programs.  ESP  was  not  compatible  with  DDT 
and  therefore  did  not  provide  the  familiar  interface  desired. 

In  view  of  the  situation,  it  seemed  desirable  to  incorporate  EDIT  into  the 
command  level,  essentially  unaltered.  EDIT  uses  a special  reader  that  either 
interprets  input  as  a conwnand  to  it  or  passes  input  on  to  the  normal  MDL  reader. 
At  first  the  task  of  superimposing  a MEND  reader  on  top  of  both  of  these 
appeared  difficult  After  much  discussion  with  the  current  maintainer  of  FDIT,  a 
very  satisfactory  solution  was  arrived  at 

A general  capability  was  added  to  EOIT  allowing  the  specification  at 
runtime  of  a table  of  EOIT-Iike  commands  to  be  handled  by  programmer  defined 
functions.  This  table  is  searched  before  EDIT*s  command  table  and  thereby 
provides  a capability  to  override  standard  EDIT  commands.  MEND  basically  uses  an 
invocation  of  EDIT  as  its  command  level  with  all  MEND  commands  included  in  a 
table  as  described.  EOlT-formet  commands  are  all  one  or  two  letters  and  may  take 
suffix  arguments.  Currently  the  MEND  table  includes  the  following  commands.  (FIX 
here  means  a MOL  object  of  type  FIX,  Le.,  a fixed-point  number.  FLOAT  means  a 
floating-point  number.  PPfWifT'*  is  a function  that  prints  a MOL  object  in  a format 
which  indicates  the  positions  of  its  elements  and  sub-elements  in  the  tree 
hierarchy.) 


NAME 

ARC  TYPE 

MEANING 

? 

nona 

typa  out  abort  aummary  of  MENO  commando 

7? 

nona 

typo  out  complata  aummary  of  all  commando 

0 

any 

Opan  objact  or  MSTACK  laval  n (if  arg  n ia  FIX) 

V 

nona 

toggla  Varboaity 

N 

FIX 

do  Naxt  n atapa  (lika  TN) 

OV 

nona 

akip  OVar  currant  objact  (lika  TO) 

Q 

nona 

(>jit  EDIT  & ratum  to  automatic  moda  (lika  TB) 

QM 

nona 

Quit  MEND  (lika  TQ) 

SN 

FIX 

Sat  Numbar  of  linaa  uaad  for  atack  diapiay 

SV 

FIX 

Sat  laVal  balow  wNch  MEND  will  not  ISTEP 

SO 

numbar 

Sat  Dalay  tima  (FIX  or  FLOAT)  batwaan  atapa 

PO 

FIX 

Pprint  Diapiayad  objact  in  laval  n 

PO 

FIX 

Pprint  Origind  (acti^)  objact  in  laval  n 

Al 

any 

Add  an  Itam  to  tha  Hat  baing  monitorad 

01 

FIX 

Dalata  Itam  numbar  n from  tha  Hat 

R 

FIX 

Pprint  Itam  numbar  n 

What  tha  uaar  typaa  to  tha  command  laval  it  inapactad  by  EDIT.  If  it 
lookv  lika  an  EDIT  command,  it  ia  lookad-up  in  tha  MEND  command  tabla  or  tha 
EDIT  ona  and  handlad  aa  appropriata.  Otharwiaa  it  ia  paaaad  to  tha  MOL  raadar. 
In  ganaral  any  intaraating  (uaafui)  input  that  MOL  ahouid  raad  and  avaiuata  will  not 
look  lika  an  EOTT  command^  ao  thara  ia  no  confuaioa 

Aa  can  ba  aaan  from  tha  tabla,  tha  MEND  commando  includa  ganaral 
Information  ratiiavai  onaa  (?  and  ?D,  ayatam  tailoring  onaa  (V,  SN,  SV,  and  SO),  and 
commando  that  allow  objacta  to  ba  aceaaaad  in  apadal  MENO  locationa  (0,  PO,  PO, 
AL  OL  and  PI).  Tha  0 command  la  apodal  In  that  it  aiiowa  an  objact  known  only  by 
ita  location  in  tha  MSTACK  to  ba  opanad  for  axamination  and  altaration  by  tha 
normal  EOIT  commando.  Tha  ramaining  commando  dupllcata  control-charactar 
commando  axcapt  that  thay  ara  raad  at  normal  input  lava!  rathar  than  at  intarrupt 
laval. 

Tha  moat  powarfui  faatura  of  tMa  command  laval  ia  aaan  whan  MOL 
objacta  ara  avakntad.  TNa  laval,  and  tharafora  tha  ovaluation,  uaaa  atack  opaca 
balow  tha  applicaUon  program  and  in  tha  aama  procaaa.  Ail  bindinga  and  ponding 
avaluationa  of  tha  program  ara  abava  tha  command  laval  whara  thay  may  ba 
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•xaminad  and  modified  at  will.  Moat  of  what  constitutes  MEND  is  in  another 
process  safely  removed  and  hidden  from  the  user.  Even  the  small  amount  of 
overhead  constituting  the  command  level  function  is  Ndden  from  functions  such  as 
FRAMES'^  which  may  be  used  to  view  the  levels  of  the  application  program’s 
current  control  stack.  The  effect  is  much  the  same  as  that  of  MDL’s  listening  loop 
which  is  invoked  at  the  current  bottom  of  the  stack  in  case  of  error,  to  allow  the 
programmer  to  run  any  program  (evaluate  any  object)  to  find  and  correct  the 
problem. 

Note  that  for  critical  axamination  of  tha  program,  the  user  may  request 
that  it  be  continued  for  a limited  number  of  steps  (usually  one)  with  control  then 
being  returned  to  Nm  or  her  at  the  command  level.  One  normally  would  employ 
such  a faature  when  the  program  Is  axecuting  statements  near  the  area  of 
suspected  trouble  but  it  is  not  entirely  clear  how  or  why  the  progrem  la 
misbehaving. 


IV.4  Breakpoints 

Normally  MEND  operates  in  automatic  mode  where  the  application  program 
is  running  continuously.  If  one  is  aware  of  a particular  area  of  concern,  one  cannot 
and  should  not  have  to  see  that  area  as  it  is  reached  and  quickly  type  tE  in  order 
to  stop  the  program.  One  may  have  the  program  running  with  a very  small  delay 
time  or  have  the  printing  turn^  off. 

In  their  simplest  form,  MEND  breakpoints  stop  the  program  when 
evaluated,  putting  the  user  in  command  moda  if  she  or  he  was  not  already  in  it 
This  is  the  MDL  equivalent  of  DOT  breakpoints,  which  stop  a program  at  a certain 
instruction.  The  breakpoints  can  also  be  conditional,  where  the  evaluation  of  an 
arbitrary  object  determines  whether  or  not  to  actually  break  at  that  point 

The  breakpoints  as  so  far  described  are  very  much  like  the  breakpoints 
that  can  be  set  by  EDIT.  As  a matter  of  fact  EDIT  is  used  to  sot  and  clear  these 
breakpoints  just  as  it  would  ba  in  the  absence  of  MEND.  The  only  real  difference 
is  that,  when  MEND  is  present  a MEND  function  is  called  to  handle  the  break 
instead  of  an  EDIT  functioa 

MEND  breakpoints  would  be  useful  even  if  they  only  did  what  was  Just 
described.  However  they  are  more  powerful.  A standard  EDIT-style  breakpoint  Is 
a call  to  the  break  function  with  a number  of  arguments.  The  first  of  these  is  the 
object  at  which  the  breakpoint  is  sat  which  will  be  evaluated  when  the  user 
returns  from  the  breakpoint  and  whose  value  will  be  returned  by  the  break 
function  to  the  application  program.  The  next  is  the  condtionai  object  and  the 
rest  are  objects  to  be  evaluated  and  printed  at  each  break.  MEND’s  break 
function  handles  these  as  EDIFs  does  but  also  looks  for  a reeogniied  ATOM 
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(variabia  nama),  wMch  may  coma  aftar  or  raplaca  tha  conditional.  If  ouch  an  ATOM 
la  founds  it  will  causa  a tpadal  action  to  occur  instaad  of  stopping  tha  program: 

ON  printing  will  bs  tumad  on  (like  tP) 

OFF  prinUng  will  be  turned  off  (like  TU) 

GO  free-run  the  object  (like  tO) 

PRINT  Just  print  srgum^s  A continue 

Other  arguments  will  still  be  printed  and  all  actions  are  still  predtoated  upon  the 
value  of  the  conditional. 

The  first  two  special  ATOMs  (ON  and  OFF),  perhaps  coupled  with  manual 
control,  are  used  to  allow  the  MSTACK  to  be  viewed  only  during  areas  of  Intareat 
while  maintaining  maximum  speed  in  other  places.  The  next  one  (GO)  is  used  to 
avoid  wasting  time  examining  the  details  of  a functional  call  that  is  known  to  be 
working  and  is  probably  evaluated  repeatedly.  When  the  break  function  returns, 
single-stepping  resumes  as  before  the  break.  The  last  special  ATOM  (PRINT)  is 
used  to  give  information  at  kay  placaa  that  might  not  otherwiaa  be  seen. 

One  thing  that  was  considered  extremely  important  was  to  make  MEMO'S 
breakpoints  compatible  with  those  of  EDIT.  The  problem  is  that  a breakpoint 
inserted  outside  of  MEND  might  still  be  present  when  MEMO  is  started  and  vice 
versa  As  has  been  stated  EDIT  breekpoints  work  almost  exactly  as  usual  when 
handled  by  MEMO's  break  functioa  The  converse  is  not  quite  trua  EDITs  break 
function  will  ignore  the  significance  of  a special  ATOM  and  simply  print  it  as  a 
normal  argumant  Fortunataly,  an  ATOM  avaluatas  to  itsalf.  If  it  is  in  the 
conditional  position  it  will  always  be  considered  "true*  and  no  harm  will  be  done. 

It  would  be  easy  to  extend  tNs  arrangement  to  other  special  ATOMs  if 
other  functions  were  co^dered  usefii.  The  sbove  seem  to  form  a basic  set  in 
tNs  system.  At  least  thay  ara  usaful  and  no  ona  has  yet  suggested  another  type 
of  breakpoint  that  would  dso  prova  usefuL 
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V Final  Thought*  ibout  MEND 
V.i  Monitoring  of  Vsluo* 

A feature  that  was  originally  considered  to  be  important,  and  is  present  in 
ESP^■^  is  the  constant  monitoring  of  values.  This  feature  has  not  been  too  happily 
received  in  MEMO,  but  that  may  be  due  more  to  the  current  implementetion  than  to 
an  inherent  lack  of  utility. 

Ideally  one  should  not  have  tc  ^ee  the  object  being  monitored  or  its  value 
if  one  does  not  want  to.  The  debugging  system  should  be  enable  of  performing 
certain  actions  upon,  for  exampio,  • change  in  value.  TNs  would  be  analogous  to 
conditional  breakpoints  except  that  the  test  would  be  performed  after  each  step 
of  execution  of  the  application  program  rather  than  at  certain  arbitrary  times. 

One  problem  with  the  above  scheme  is  the  difficulty  of  testing  for  a 
change  in  value  (the  basic  test).  For  example,  the  value  of  an  object  being 
monitored  may  be  some  sort  of  structure.  During  execution  the  application 
program  may  not  explicitly  change  the  value  of  the  object  but  may  change  an 
elentent  of  the  structure  tlwt  the  object  evaluates  to.  Assuming  MEM3  had  saved 
a pointer  to  the  structure,  if  it  now  evaluated  the  object  being  monitored,  it  would 
again  find  that  structure  and  assume  that  the  value  had  not  changed.  However 
since  an  element  of  the  structure  had  changed,  the  programmer  would  probably 
want  to  be  notified. 

The  only  solution  to  the  above  dilemma  is  to  at  each  step  save  a complete 
representation  to  all  levels  of  the  value  of  the  object  In  some  form  that  cannot  be 
affected  by  the  application  program.  TNs  can  be  done  by,  at  each  step,  unparsing 
the  value  to  be  saved  for  future  tests  into  its  printed  (string)  representation. 
Then  the  comparison  of  currant  and  previous  values  will  simply  bo  a string 
comparison,  not  subject  to  sharing  by  the  values.  Unfortunately  tNs  may  create 
incredible  amounts  of  "garbage.”  In  fact,  a circular  list  (quite  legal)  will  produce  a 
string  of  infiNte  length! 

The  solution  finally  chosen  was  to  print  the  values  of  the  objects  being 
monitored  at  each  step  and  to  let  the  user  Usually  compare  versions.  The  values 
are  &-printed  as  usual  but  may  be  examined  in  full  at  will. 

When  tested  it  became  immediately  obvious  that  the  constant  reprinting 
wasted  time  and  was  distracting.  A feature  was  added  to  cause  printing  to  occur 
only  at  controllable  intervals,  but  that  producad  othar  problems.  Primarily  the  user 
mi^t  not  see  a change  that  had  occurrad  at  one  step  until  some  later  step  when 
valuable  information  had  already  been  lest.  One  would  alto  not  have  the 
opportunity  to  take  immediate  action. 

What  needs  to  be  done  at  tNs  point  is  to  reduce  the  emphasis  on  such 
pathological  cases  as  described  above.  Printing  should  oNy  occur  at  well  defined 
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moments  (i.e.,  when  requested  or  when  some  recognizeble  condition  occurs).  Only 
gross  end  eesily  testsbie  chenges  in  value  should  be  watched  for  (i.e.,  the  value  is 
a new  object,  entirely).  Conditional  monitoring  shouid  be  inatalied  aneiogous  to  the 
conditions  of  breakp^nts.  With  all  of  tNs  testing,  a variety  of  indicationa  ahould 
be  available  as  with  breakpoints. 


V.2  Control  Stack  Display 

MEMO’S  display  of  the  application  program’s  control  stack  has  proven  to 
be  by  itself  a highly  useful  dabufging  aid.  TNs  display  can  be  and  often  la  uaed 
without  any  of  MEMO’s  other  features  to  debug  a faulty  program,  it  riMuid  also  be 
emphasized  that  a valid  use  of  tNs  display  is  to  monitor  a working  program  in 
order  to  understand  its  operation.  In  tNs  case,  where  the  user  of  MEMO  is 
completely  unfamiliar  with  the  operation  of  the  application  program,  MEMO’s 
step-by-step  display  of  program  execution  is  even  more  useful  than  in  tlw  normal 
detxjgging  situation 

One  of  the  unique  features  of  Ml^’s  "trace"  of  the  application  program  is 
that  MEMO  shows  both  the  code  being  executed  and  tha  results  of  that  execution 
Since  MOL  is  an  applicative  language,  most  of  the  results  consist  of  values 
returned  by  evaiuaM  objects.  By  reflecting  the  returned  values  back  into  the 
original  code,  MEMO  shows  intermediate  results  in  an  intuitive  manner  for  the  user. 

Other  programming  languages  could  also  benefit  from  tNs  sort  of  display. 
Too  often  a trace  routine  provided  for  debugging  in  a language  shows  only  re^ts 
of  execution,  such  as  value  assignments,  without  showing  the  corresponding 
program  stops,  or  it  shows  program  steps  but  leaves  it  to  the  programmer  to 
Insert  instructions  to  show  intermediate  resulta.  What  the  programmer  really 
needs  to  see  is  a well  integrated  display  of  both  program  instructions  and  resulta, 
ouch  aa  MEMO  provides. 

MOL  is  an  exceptional  language  in  that  the  MEMO  display  was  implemented 
fairly  deaNy  with  just  a package  of  MOL  functions  and  with^  changes  to  the 
interpreter  itself.  With  suitable  language  enhancements,  however,  a similar  display 
could  be  provided  for  LISP  or  any  ether  LiSP-like  language.  Although  major 
compiler  modifications  would  be  required^  a stack-oriented  display  might  also  be 
ouitMe  for  a block  structured  language  like  ALGOL 

Especially  in  a block  structured  language,  where  instructions  might  be 
treated  in  groups  rather  than  individually,  but  alao  in  applicative  longueges,  it 
would  be  useful  to  be  shown  variable  bindings  aa  they  occur.  MOL  does  not 
provide  any  information  about  the  occurrence  of  bindings  so  the  programmer  is  not 
informed  of  such  occurrences  by  MEND.  However  when  major  modificationa  are 
made  In  a language  to  provide  a (fspley  similar  te  MEND'ib  it  would  probably  be  e 


- "i. 


mittaka  not  to  induda  a provision  for  notifyinf  tha  programmar  of  variabla  bindings 
and  unbindings  as  they  occur. 


V.3  Simulation  Vs.  Multiprocessing 

Besides  its  control  stack  display,  MEND’s  other  major  feature,  and  its 
major  difference  from  debugging  systems  like  ESP  or  the  first  version  of  MUMBLE, 
is  its  use  of  multiprocessing  rath^  than  simulation  to  follow  application  program 
executioa  (Even  debugging  aids  that  use  multiprocessing  often  do  not  work  the 
way  MEND  does.  While  MEND  Is  a program  written  in  the  same  language  and 
running  concurrently  in  the  same  interpreter  as  tha  application  program,  some 
debuggers,  such  as  DDT,  are  machine  language  programs  running  "near”  the 
application  program,  and  othars  ara  simply  compilad  into  the  language  itself.)  This 
feature  is  perhaps  the  key  to  MEND’s  success  as  a debugger.  The  choice  to  avoid 
simulation  certainly  reduced  tha  size  and  complexity  of  MEND  by  two  or  three 
times  and  similarly  affected  run  time.  What  remains  to  be  discussed  are  the 
tradeoffs  involved  in  the  choice.  The  advantages  just  mentioned  heavily  favor  the 
multiprocessing  solution  but  there  ara  other  considerations. 

If  MEND  had  been  implemented  using  simulation,  it  would  for  the 
evaluation  of  each  object  determine  wNch  elements  need  evaluation;  evaluate 
those  elements  by  recursively  calling  MEND’s  own  evaluation  simulator;  determine 
whether  some  function  should  be  applied;  determine  the  effects  of  the  required 
functional  application,  if  any;  and  causa  thosa  effacts  whiie  displaying  some 
representation  of  them  for  the  programmer.  In  short,  MEND  would  du^icate  the 
actions  of  MDL  while  maintaining  and  updating  its  own  information  about  those 
actions.  Therefore  MEND  would  at  all  times  know  exactiy  what  the  application 
program  was  doing  and  could  never  miss  some  important  effects  of  execution  or 
be  fooled  by  an  unusual  program.  In  the  previous  section  it  was  stated  that  it  is 
desirable  to  show  the  occurrence  of  variabla  bindings  to  the  programmer.  This 
feature  would  be  easy  to  implement  In  a debugging  system  that  simulated 
execution  of  the  application  program. 

But  what  about  a debugging  system  using  multiprocessing?  A 
multiprocessing  debugger,  such  as  MEND,  allows  the  application  program  to 
execute  more-or-less  freely  in  its  own  process  wNIe  monitoring  it  from  another 
process.  Since  MEND  is  not  in  direct  control  of  the  application  program^  it  must 
rely  for  its  information  on  whatever  data  It  Is  given  by  the  multiprocessing 
mechanism  built  into  MDL  and  on  inferences  based  on  examination  of  the 
application  program’s  environment,  its  knowledge  of  the  general  behavior  of  MDL 
programs,  and  soma  specific  knowledge  of  special  cases.  The  occurrence  of 
variable  Mndings  is  not  decipherabla  from  the  information  that  MEND  can  gather. 
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Fortunately,  at  hat  bean  previously  thown,  MEND  doat  have  the  information 
attantial  to  the  creation  of  itt  ditplay  and  the  ditplay  it  a tuffidant  debugging 
tool. 

Monitoring  execution  of  the  application  program  from  another  procett 
providet  tuffident  information  for  a uteful  debugging  tyttem  while  timulation  of 
the  application  program  providet  enough  information  for  a more  comprehentive 
tyttem.  Therefore,  if  tpeed  and  dze  of  the  debugger  were  not  important  factora, 
then^  although  not  a necettary  chdca,  timulation  would  be  the  favored  choice  for  a 
debugging  tyttem  except  for  one  other  factor. 

The  timulator  needt  much  more  knowledge  of  tpecific  detailt  of  the 
behavior  of  program  functions  than  does  the  monitor.  In  fact  the  timulator  must 
know  exactly  the  effects  of  each  function  that  might  be  used  in  the  application 
program.  Uncompiled  user-defined  functions  are  no  problem.  They  consist  merely 
of  one  or  more  applications  of  other  functions  to  given  arguments.  Compiled 
user-defined  functions  cannot  be  dealt  with  at  all  without  actually  creating  a 
simulator  for  macNne  language  programs,  a project  comparable  in  magnitude  to  the 
design  and  implementation  of  all  of  the  other  parts  of  the  simulator  combined!  The 
remaining  functions  are  MDL’s  built-in  primitives.  They  are  well  defined  but 
frequently  change  (usually  upward  compatibly).  Furthermore  new  primitives  are 
constantly  being  added.  A simulator  for  MDL  programs  would  therefore  quickly 
become  outdated 

Given  the  problems  of  a simulator  and  the  relatively  few  drawbacks  of  a 
monitor,  it  is  clear  now  why  MEND  was  impiamented  as  the  latter.  The  same 
arguments  apply  to  debug^ng  systems  for  other  languages.  Whenever  the 
appropriate  multiprocessing  features  exis^  with  sufficient  information  available 
ab^  execution  in  another  process,  a dabugning  systam  based  upon  simulation  of 
the  application  program  should  be  rejected  in  favor  of  a monitor-type  system. 
MEND  hes  proven  to  be  an  effective  debugging  aid  and  should  serve  as  a good 
example  of  the  letter  type  of  system 
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VI  Su»g«ition«  for  Future  Work 
VLl  Monitoring  of  Accost 

Because  of  the  problems  described  in  Section  V.l  concerning  the 
monitoring  of  values,  there  was  not  enough  time  to  work  on  a related  but  more 
interesting  feature  for  MEND.  Frequently  the  mein  piece  of  information  that  la 
available  about  a bug  in  a program  is  that  at  tome  point  a certain  data  area 
(variable  value,  list  slot,  etc.)  is  being  'dobbarecT  by  function(s)  unknown. 

Rather  than  watching  the  program  execution  in  detail  to  find  the  culprit,  it 
would  be  far  more  useful  to  set  a "breakpoint"  on  access  to  the  location  in 
questioa  This  could  be  done  by  having  MEMO  redefine  ail  data  access  functions  to 
watch  for  certain  locations.  Not  only  would  that  be  messy,  but  it  goes  against  one 
of  the  basic  philosophies  of  MEND.  With  good  reason,  as  described  earlier,  MEND 
tries  to  alter  its  environment  as  little  as  possible.  (For  example,  what  if  the 
application  program  redefined  one  of  the  functions  also?) 

MOL  again  provides  the  answer.  The  code  already  exists  for  monitoring 
read  or  write  access  to  any  standard  data  location  It  is  only  necessary  to  set  up 
the  proper  type  of  interrupt  handler  with  a pointer  to  the  location  to  Im  watched 
Each  time  the  specified  type  of  access  occurs,  the  handier  will  be  called  with  all  of 
the  particulars. 

MENO  should  hava  commands  instailad  for  creating  and  destroying  such 
handlers.  For  consistency  and  to  facilitate  remembering  for  the  user,  the  possible 
actions  of  this  handier  upon  being  called  should  be  similar  to  those  of  breiritpointa 
and  of  monitoring  of  values. 


VL2  Other  Unimplemented  Features 

Three  other  proposed  features  were  not  implemented  due  to  an  acquired 
belief  that  the  value  of  each  of  these  features  in  relation  to  the  goals  of  this  work 
was  not  worth  the  time  required  to  properly  impiamant  it  However  each  of  these 
features  has  merit  and  may  ba  daslrabla  in  soma  future,  more  comprehensive 
debugging  system. 

The  first  such  feature  involves  saving  ail  output  of  the  application 
program  for  the  programmer  to  refer  back  to.  This  has  the  implementation 
difficulty  that  there  is  no  easy  way  to  separate  application  program  output  from 
much  of  the  MENO  output.  All  application  program  output  and  certain  MEND  output 
goes  to  the  lower  section  of  the  screen  utilizing  the  same  output  mechanism  (Le., 
standard  MDL  output  to  the  primary  terminal  output  channel).  No  distinction  la 
made  between  the  two  kinds  of  output  A distinction  could  be  made  by  having 


MEND  do  all  of  its  output  through  yet  another  terminal  output  channel  (a  second 
channel  is  currently  used  for  (he  upper  Kreen  section),  (Kit  another  consideration 
made  the  effort  seem  not  worthwhile  In  practice,  programs  that  produce  a lot  of 
output  usually  send  it  to  a fiia  and  not  to  the  terminal.  Since  only  small  amounts  of 
output  are  u^ly  sent  to  the  terminal,  a short  output  Nstory,  such  as  that  wNch 
is  present  on  the  screen  itself,  is  generally  sufficient 

The  second  unimplemented  feature  would  have  allowed  the  setting  of 
MEMO  breakpoints  using  the  editor  IMEO.  This  would  have  meant  sending  a 
function  out  to  the  IMLAC  where  iocal  editing  would  have  been  used  to  create  or 
delete  such  breakpoints.  PRINTTYPE  and  REAO-TABLEs  would  have  been  used  to 
allow  for  setting  normal  breakpoints  and  the  special  MEND  types  (ON,  OFF,  etc.) 
usir^  one  or  two  mnemonic  characters. 

The  primary  reason  that  tNs  feature  was  not  implemented  was  that  EDIT 
was  chosen  to  be  the  MEND  editor  instead  of  IMEO.  That  choice  was  ntade  partly 
because  EDIT  is  in  many  respects  the  more  powerful  of  the  two,  but  mostly 
because  EDIT  is  the  editor  now  used  almost  exclusively  by  MOL  programmers.  In 
fact,  EDIT  is  now  pra-ioaded  in  MDL  while  IMED  is  not.  Another  reason  for 
rejection  of  this  feature  was  that  it  would  have  made  MEND,  or  at  least  tNs  part 
of  it,  terminal  dependent 

In  a different  environment  a similar  feature  might  be  quite  useful.  IMED 
still  hes  the  large  advantage  over  EDIT  that  by  constantly  displaying  the  entire 
function  wNIe  the  programmer  moves  the  cursor  around  in  it,  creating  and  deleting 
MEND  "command  symbols”  at  will,  the  user  is  provided  with  a much  better  feel  for 
the  debugging  environment  being  set  up  than  with  EDIT. 

The  third  feature  would  allow  the  user  to  reverse  execution  of  the 
application  program  or  to  simply  bKk  up  to  soma  pravious  point.  This  was 
suggested  in  two  varieties,  an  actual  undoing  of  ail  affacts  of  the  program  on  a 
step-by-step  basis  or  $lm^y  showing  pr^vloui  states  of  the  MSTACK.  The  first 
version  would  have  used  UNOO'^  a packaga  of  functions  to  actually  back  up  a 
program  to  some  previous  state.  UNDO  however  violates  a primary  design  goal  of 
MEND.  It  works  by  redefimng  every  MOL  function  that  has  a side-effact,  theraby 
causing  most  of  the  negative  effects  of  simulation  that  ware  previously  discussed. 
Unfortunately  tha  way  UNDO  works  is  really  the  only  reasonable  way  such  a 
package  could  work,  short  of  modifying  MOL  IMf,  and  even  UNDO  is  net  foolproof. 

The  oNy  practical  way  tNs  feature  could  be  impiemanted  is  in  its  second 
variety.  It  would  be  possIMe  to  store  (in  a fila,  probably)  information  specifying 
the  state  of  the  MSTACK  at  each  step  and  to  allow  tiM  programmer  to  view 
previous  steps  in  soma  comfortable  mannar.  Tha  time  required  to  implement  tNs 
feature^  thouglv  put  it  outside  of  tha  scope  of  tNs  work. 
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VI.3  Immediate  Action  Commands 

'impirical  evidence  suggests  that  one  more  interrupt-level  immediete 
action  command  would  be  highly  useful.  Currently  the  user  may  skip  over  the 
complete  execution  of  a single  object  by  typing  TO  just  after  the  object  is  placed 
on  the  stack  for  evaluation.  The  user  may  also  want  to  rapidly  complete  the 
evaluation  of  some  object  that  is  already  executing.  Fpr  example,  one  may  have 
watched  the  first  few  objects  in  a REPEAT  loop  being  evaluated  and  now  wants  to 
free-run  the  application  program  until  the  looping  is  finished.  For  such  a case,  a 
command  should  be  available  to  skip  over  the  evaluation  of  the  current  object  and 
all  others  at  the  same  level  (i.e.,  finish  evaluation  of  the  object  on  the  previous 
level). 

Further  use  of  MEND  may  indicate  a need  for  other  interrupt-level 
commands.  (Perhaps  certain  interrupt-level  commands  should  somehow  be  able  to 
take  arguments?) 
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VI.4  Terminal  Handling 


The  MSC  implementation  of  MEND  was  discarded  because  of  problems 
specific  to  the  current  operating  environment.  In  a suitable  environment, 
n^ti-screening  is  still  seen  to  be  a useful  feature  for  a similar  debugging  system. 
It  has  even  been  suggested  that  something  of  the  sort  could  be  implemented  using 
two  separate  terminals.  One  terminal  would  look  to  the  application  program  just 
like  the  terminal  it  would  have  seen  in  the  absence  of  MEND.  The  other  terminel 
would  be  used  for  communications  with  MEND.  Not  only  would  this  eliminate 
output  conflicts  between  the  application  program  and  MEND,  but  with  two 
keyboards  there  would  be  no  need  to  have  a reserved  character  set  for  MEMO 
interrupt-level  commands.  Of  course,  it  might  be  difficult  for  the  user  of  such  a 
system  to  coordinate  activities  between  the  two  terminals. 

Another  area  where  MEND  might  be  improved  is  its  knowledge  of  the 
terminal  being  used.  As  has  been  previously  discussed,  it  currently  assumes 
certain  basic  display  functions  and  relies  i4>on  ITS  to  understand  the  requirements 
of  the  terminal.  Although  ITS  handles  the  job  well,  it  Is  not  the  only  operating 
system  that  MDL  may  run  under.  TNs  author,  in  fact,  actively  uses  MDL  under 
TENEX,  an  operating  system  that  leeks  the  terminal  code  to  support  MEhK).  To 
properly  work  under  most  operating  systems,  MEND  would  have  to  be  tailorable  to 
individual  terminal  codes  and  requi*’oments  ai^  would  have  to  do  much  more  of  the 
work  than  under  ITS. 

It  has  been  proposed  that  MEND  could  be  made  to  work  In  some  fasNon 
with  the  basic  ASCII  printing  terminal,  something  that  nearly  all  terminale  and 


operating  tyttemt  can  timulata.  Howavar  it  it  the  opinion  of  tMt  author  that 
MEND  wouid  lota  much  of  itt  valua  under  tuch  conditlont.  Watching  the  ttack 
grow  and  thrink,  and  teeing  objaett  rapiacad  by  their  valuat,  givat  the  utar  more 
of  a ”faal”  for  what  the  application  program  it  doing  than  a long  atraam  of 
taquantlally  printed  llnat  aver  eouUL 
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Appendix  A;  Sample  Display 

What  follows  is  an  excerpt  from  a sample  MEND  debugging  session 
showing  the  main  display  area  (at  the  top  of  the  screen)  for  a series  of 
consecutive  steps.  That  which  appears  between  the  dotted  lines  is  what  was 
displayed  at  each  step  of  the  program.  The  program  being  so  displayed  is  a simple 
exponentiation  function  being  applied  to  2 and  3.  The  definition  of  this  function  is 
printed  in  full  (using  PPRINT)  before  the  sample  displays. 

The  words  printed  on  the  separator  line  show  the  state  of  several  flags. 
"Print,”  "auto,”  and  "next"  mean  that  printing  is  enabled,  MEND  is  in  automatic  run 
mode,  and  MEND  is  waiting  for  the  next  object  to  be  typed,  respectively.  The 
numbers  on  the  left  show  the  depth  of  evaiuation  The  initial  object,  as  originally 
typed  by  the  programmer,  is  placed  at  level  0.  "MENDING"  was  returned  by  MEND 
when  the  system  was  started  The  next  line  shows  the  user’s  typein  of  the  initial 
object  (terminated  by  "S”).  Below  this  line,  in  the  last  step,  MOL  printed  the 
object  that  the  initial  object  returned  Explanatory  comments  appear  to  the  right 
of  semicolons. 

Here  is  the  definition  of  the  exponentiation  function: 

<0£FINE  EXP  (X  Y) 

<coao  {<0?  .Y>  1) 

(<»  <EXP  .X  <-  .Y  1»  .X»» 


w 
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. . . 

t Savaral  initial  diapiaya  omittad 

0 

<EXP  2 3> 

) Initial  objaet  baing  avaluatad 

1 

<CONO  (IFALSE  ()  1)  t> 

i Body  of  tha  EXP  function  ia  Juat  a COM)  FORM. 

2 

(t) 

1 Clauaa  of  tha  pravioua  OOND  baing  avakialad 

i 

<*  ♦ .X> 

{ Only  aiamant  ^ tha  abova  dauaa. 

4 

<EKr  2 2> 

S 

<CONO  (IFALSE  ()  1)  t> 

6 

(t) 

7 

<«  ♦ .X> 

6 

<EXP  2 «> 

9 

<-  .Y  1> 

} Moat  currant  aiamant  baing  avaluatad 

orlnt  auto 

‘‘HENDINfi- 

; Mataaga  ratumad  by  function  that  atarta  MENO. 

<EXP  2 

3>S 

; Objact  to  ba  avaluatad  and  dabuggad 

V ? 
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0 <EXP  2 3> 

1 <COND  (tFALSE  ()  1)  t> 

2 (♦> 

3 <»  t .X> 

4 <E)0»  2 2> 

5 <COND  (tEALSE  ()  1)  i> 

6 (♦) 

7 <*  i .x> 

6 <EXP  2 t> 

9 <-  ♦ l> 

10  .Y 


or Int  auto 

"MENDING" 

<E)(P  2 3>S 


0 CEXP  2 3> 

1 <C0ND  (OFALSE  ()  1)  t> 

2 (t) 

3 <•  ♦ .X> 

4 <EXP  2 2> 

$ <C0N0  (OFALSE  ()  1)  t> 

0 (t) 

7 <•  ♦ .X> 

0 <EXP  2 t> 

9 <-  ♦ 1> 

10  2 


pr Int  puto 

"MENDING" 

<EXP  2 9>S 
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0 <EXP  2 3> 

1 <CONO  (IFALSE  ()  1)  t> 

2 (♦) 

3 <•  t .X> 

4 <EXP  2 2> 

5 <COW)  (IFALSE  ()  1)  t> 

6 (t) 

1 <•  t .x> 

6 <EXP  2 1> 


print  auto 

"HEN0IN6" 

<E)(r  2 3>3 


<E)(F  2 3> 

<C0N0  (IFALSE  ()  1)  4> 

(♦) 

<•  t .X> 

<EXF  2 2> 

<C(MD  (IFALSE  ()  1)  t> 

(t) 

<•  t ,X> 

axr  2 1> 

<C0II0  «ir  .Y>  1)  «•  <B9  .X  <•  .Y  i»  .X»> 


ICHOINfi* 
<EXf  2 in 


print  PMto 
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0 <E)9  2 S> 

1 <CONO  (iFALSe  0 1)  t> 

2 (♦) 

3 <0  t .X> 

4 <EXP  2 2> 

5 <C0N0  (iFALSE  ()  1)  t> 

6 («) 

7 <*  i .X> 

e <EXP  2 1> 

S <C0II0  t (<•  <»f  .X  <•  .Y  1»  .X»> 

10  (<0?  .Y>  1) 


<EXr  2 3> 

<C0II0  (iTALSE  0 1)  t> 

(♦) 

<•  t .X> 

<EXr  2 2> 

<CONO  (fFALSE  ()  1)  Y> 

(♦) 

<•  ♦ .X> 

<EXP  2 1> 

<C0N0  f (<•  <EXP  .X  <-  .Y  1»  .X»> 

0 («  1) 

1 <lf  .Y> 

Tint  iito 

"HENOINfi” 

<CXP  2 3>t 


f 

I 


i 

I 


1 

I 
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4 <cxp  2 2>  i ScrolMng  hts  oocurrwi  tine*  th«  iMt  display 

5 <CONO  (IFALSE  ()  1)  t> 

6 (4) 

7 <•♦.)(> 

6 <EXP  2 1> 

9 <coao  ♦ (<•  <E»  .X  <-  .y  i»  .»)> 

10  a 1) 

11  <07  t> 

12  .Y 


pr  Hit  •uto 

-HEN0IN6" 

<EXP  2 3>$ 


4 <EM>  2 2> 

5 <C0N0  (IFALSE  ()  1)  t> 

6 (t) 

7 <•  ♦ .X> 

a <EXP  2 1> 

9 <COm  t (<o  <EXF  .X  <-  .Y  1»  .X»> 

10  (t  1) 

11  <07  t> 

12  1 


Bflnt 

-MENOIW* 

<EXP  2 S>S 
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i <EXP  2 2> 

<CONO  (ITALX  0 1)  t> 

; («) 

<•  ♦ .» 

I <cxr  2 1> 

I <coiio  t (<•  <cxr  .X  <•  .Y  i»  .x»> 

0 (t  1) 

1 <or  i> 


■rmt  nU 

"MEKOIIK” 

<tXf  2 J>» 


4 <EXf  2 2> 

5 <C0ND  <IFALSE  ()  1)  t> 

« (f) 

7 <•  ♦ .X> 

S <EXP  2 1> 

S <0X10  t (<•  <CXP  .X  <•  .Y  1»  .X»> 

It  (t  1) 

11  itALSC  0 


Tint  lU 

"fCKOlW” 

<Exp  2 m 
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; Stvtrd  dl tpi«y«  omittwl 


0 <EXP  2 3> 

1 <C0N0  (tFALSE  ()  1)  t> 

2 («) 

3 <•  4 2> 


"MENDING" 
<EXP  2 3>$ 


i 

I 


I 


0 <EXF  2 3> 

1 <CONO  (ITALSE  ()  1)  t> 

2 (♦) 

3 6 


print  auto 


Of Int  onto 

"MENDING* 

<V9  2 3>$ 
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0 6 


( Mtid  objtet  rtUrtw  tNt  viiut. 


Of  int 

ICNOING" 

<E)»  2 i>% 


0 S 


mt  Mite 


'ICIIDIW* 

oxr  2 9>» 


I FImI  vilut  It  rtliiiwd  by  MOL  In  eorrwt  terMii  loetUort 


Appudix  B;  GloMary  of  Terwt 


ISTEP* 

ATOM* 

CONO* 

OOT*^ 

OEBUGR 

EDIT" 

ENVnONMENT* 

ESP*** 

EVAL* 


A function  pre-loaded  in  MDL  that  printe  objects  in  an 
abbreviated  form  to  fit  in  a programmer-specified  number  of 
, character  positions. 

A built-in  MDL  function  used  by  one  program  to  single-step 
another  for  debugging  purposes. 

A MDL  variable. 

A built-in  MDL  function  providing  a general  conditional  capability. 
The  arguments  to  COND  are  lists.  MOL  evaluates  the  first 
element  of  each  list  in  turn  until  an  element  returns  a non-false 
value.  Then  the  rest  of  the  elements  in  the  current  list  are 
evaluated  and  COND  returns  what  the  last  element  in  the  list 
returns. 

A program  used  to  debug  assembly  language  programs. 

A program  utilizing  MOL's  single-stepping  functions  to  show  a 
programmer  the  step-by-step  execution  of  a program.  DEBUGR 
is  an  attempt  to  provide  a OOT-like  debugger  for  MOL  programs. 

A pre-loaded  editor  for  MOL  objects.  EDIT  works  witNn  MDL 
by  restructuring  the  object  being  EDITed  according  to  the 
specifications  of  the  programmer,  EDIT  allows  one  to  define 
one’s  own  commands  or  to  redefine  those  of  EDIT. 

A MDL  object  which  specifies  a particuiar  set  of  variabie  bindings. 
An  ENVIRONMENT  is  normally  cumulatively  built  up  as  the  control 
stack  of  a program  builds  and  ATOMs  are  bound.  The 
ENVIRONMENT  actually  corresponds  to  a particular  point  on  the 
control  stack.  A program  may  have  an  object  evaluated  in  an 
ENVIRONMENT  specifying  the  current  state  of  another  running 
program.  The  effect  is  as  if  the  latter  program  had  evaluated  the 
object 

A debugging  systam  for  assambiy-ianguaga  programa. 

A built-in  MOL  function  that  avaluatas  an  objact  and  ratuma  the 
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valu*  of  that  objact 

FIX*  A MOL  object  that  it  an  integer. 

FLOAT*  A MOL  object  that  it  a floating-point  number. 

FORM*  A iitt  of  MOL  objects  which  is  evaiuated  by  appiying  the  first 

element  (some  function)  to  the  rest  of  the  elements  (its 
arguments).  "Execution”  in  MOL  generally  refers  to  the 
evaluation  of  a FORM.  The  evaluation  of  that  FORM  will  often 
require  the  evaluation  of  other  FORMs  (the  arguments  to  the 
function  or  FORMs  in  the  body  of  the  function). 

FRAMES'*  A pre-loaded  function  that  shows  the  programmer  a printed 
representation  of  the  control  stack  of  the  current  program. 

IMEO  An  editor  for  MOL  objects  that  works  by  outputting  an  object  to 

the  IMLAC  where  local  editing  functions  are  used 

IMLAC  A minicomputer  with  a keyboard  and  CRT  display  used  as  an 

intelligent  termind. 

ITS'*  A general-purpose  time-sharing  operating  system  davalopad  by 

the  Artifidd  Intdiigence  Laboratory  at  M.LT. 

LVAL*  A built-in  MOL  function  that  returns  the  locd  vdue  of  a given 

ATOM.  The  locd  value  is  that  which  was  last  bound  to  the 
ATOM  in  the  current  ENVIRONMENT. 

MOL*  An  applicative  programming  language  used  to  implament  MEND. 

MEND  Mdl  Executor,  aNdyzer,  and  Oebuggar.  The  subject  of  this 

report 

MSC  Multi-Screen  Console  program  for  an  IMLAC.  This  gives  the 

IMLAC  used  as  a termind  a capability  for  having  severd  virtud 
screens  that  may  be  accessed  and  dismayed  independently. 

A structure  that  MENO  builda  to  contdn  a representation  of  the 
control  stack  of  tha  application  program 


M8TACK 


ySi* 
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MUMBLE'  An  early  debugging  aid  for  MDL  programa  providing  a (fiaplay  of 
the  application  program’a  control  atack. 

PPRINT'*  A pre-loaded  MDL  function  that  "Pretty-PRINTa"  an  object  in  a 

format  which  indicatea  the  poaitiona  of  ita  elementa  and 
aub-elements  in  the  tree  hierarchy. 

PRINTTYPE*  A built-in  MDL  function  allowing  the  programmer  to  apecify  exactly 
how  any  particular  type  of  object  ahould  be  piint^  May  be 
used  to  output  charactera  that  will  be  Interpreted  aa  apeclal 
commands  on  input  See  READ-TABLE 

PROG*  A built-in  MDL  function  uaed  for  aequential  execution  of  MDL 

objects  {generally  FORMs).  This  function  providea  for  binding  of 
ATOMa  to  be  used  within  the  PROG'a  acopa  and  then  evaluates 
each  of  the  objects  in  ita  body,  usually  in  order.  It  is  possible, 

I however,  to  alter  the  flow  of  control  by  branching  forward  or 

backward  to  another  part  of  the  PROG  body.  See  REPEAT. 

READ-TABLE*  A table  that  may  be  set  up  in  MDL  to  apecify  hew  any  character 
ahould  be  treat^  on  input  See  PRINTWpE 

REPEAT*  Like  PROG  except  that  when  the  end  of  the  body  of  objects  la 

reached,  control  returns  to  the  beginning. 

SSV'*  The  normally  uaed  IMLAC  console  program.  See  MSC. 


UNDO'*  A MDL  program  that  stores  information  about  the  execution  of  an 

application  program  so  that  the  execution  may  be  backed  up  to 
some  previous  point  at  any  time. 
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